Fabric assisted identity and authentication

ABSTRACT

Context-based authentication in a secure network comprised of multiple interconnected programmable devices is described. One technique includes receiving, from a programmable device, identity data and contextual data associated with a current authentication of a user attempting to access a secure network. The user is associated with the programmable device. The technique may include determining, based on the identity data and the contextual data, one or more patterns associated with the current authentication of the user. Furthermore, a risk level associated with the current authentication of the user may be determined based on the identity data, the contextual data, and the one or more patterns. In at least one scenario, access is granted to the secure network in response to the determined risk level. Other advantages and embodiments are described.

TECHNICAL FIELD

Embodiments described herein generally relate to the field ofauthentication (e.g., restricting access by persons to machines, places,and/or data, etc.). More particularly, embodiments described hereinrelate to context-aware authentication techniques.

BACKGROUND ART

Programmable devices—such as internet of things (IoT) devices, mobilecomputing devices, desktop computing devices, and cloud computingdevices—can make up a computer network of interconnected programmabledevices (hereinafter “a computer network”). A user operating one ofthese programmable devices may have to be authenticated before access isgranted to the computer network.

Authentication can be defined as one or more processes used to verify auser identity attempting to access a secure computer network. Ingeneral, authentication includes comparing identity data (that isprovided by a user attempting to gain access to a secure computernetwork) to stored information comprising authorized users' information.

Conceptually, identity data can be broken up into three authenticationfactors—(i) a knowledge factor, which is information known to the user(e.g., a password, a username, etc.); (ii) an ownership factor, which isa physical or virtual object possessed by the user (e.g., anidentification card, a security token, a software token, a hardwaretoken, a device with a hardware and/or software token, etc.); and (iii)an inherence factor, which is an intrinsic characteristic of a user(e.g., fingerprint, retinal pattern, DNA sequence, face, voice, uniquebio-electric signals, other biometric identifier, etc.).

Based on the factors above, there are different types ofauthentication—single-factor authentication, two-factor authentication,and multi-factor authentication. The higher the number of authenticationfactors used in an authentication technique, the stronger and less proneto security compromises (e.g., man-in-the-middle attacks, etc.) that theauthentication technique will be.

Many organizations use single-factor, two-factor, and/or multi-factorauthentication for granting access to their secured systems. One issueassociated with these techniques of authentication is their inability totake context or risk into account when attempting to authenticate anindividual. For example, an authentication technique will always requirea user's username and password regardless of whether the user isaccessing an organization's information system from a secure terminal(e.g., an organization-approved computer system, etc.) or from aunsecure terminal (e.g., the user's personal computer system, etc.).

Even though a secure network that always requires the use of one or morefactors for access may protect against unauthorized access, such asystem may also be an inefficient system. For example, a significantamount of resources (e.g., human resources, computer resources, etc.)must be maintained and deployed each time a user attempts to access thesecure network. As the number of users with authenticated access to sucha system increases, the amount of resources associated withauthentication can increase significantly.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating a computer network capable ofperforming context-aware authentication according to one embodiment.

FIG. 2 is a sequence diagram illustrating a technique for context-awareauthentication that is implemented in a context-aware network accordingto one embodiment. The context-aware network of FIG. 2 can be part ofthe computer network illustrated in FIG. 1.

FIG. 3 is a block diagram illustrating an enterprise service bus (ESB)for use in context-aware authentication according to one embodiment. TheESB of FIG. 3 can be part of the context-aware network illustrated inFIG. 2.

FIG. 4 is a flowchart illustrating a technique for context-basedauthentication according to one embodiment.

FIG. 5 is a block diagram illustrating a programmable device for usewith techniques described herein according to one embodiment.

FIG. 6 is a block diagram illustrating a programmable device for usewith techniques described herein according to another embodiment.

DESCRIPTION OF EMBODIMENTS

Embodiments described herein relate to context-aware authenticationtechniques. As such, one or more of the embodiments described hereinacts as an improved alternative to one or more currently-availableauthentication techniques that fail to factor in context or risk.Consequently, at least one of the embodiments described herein isdirected to improving computer functionality by intelligently improvingauthentication techniques used for accessing secure networks. Inparticular, at least one of the embodiments described herein can assistwith dynamically adjusting an amount of authentication required for auser to gain access to a secure network based on one or more attributesassociated with the user. This dynamic adjustment of authenticationrequirements can in turn assist with minimizing or eliminating risks tothe operational integrity of a secure network caused by vulnerabilitiesin the authentication technique on an as-needed basis. In this way,computer resources associated with authentication can be utilized moreefficiently.

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the embodiments described herein. It will be apparent,however, to one skilled in the art that the embodiments described hereinmay be practiced without these specific details. In other instances,structure and devices are shown in block diagram form in order to avoidobscuring the embodiments described herein. References to numberswithout subscripts or suffixes are understood to reference all instanceof subscripts and suffixes corresponding to the referenced number.Moreover, the language used in this disclosure has been principallyselected for readability and instructional purposes, and may not havebeen selected to delineate or circumscribe the inventive subject matterin the embodiments described herein. As such, resort to the claims isnecessary to determine the inventive subject matter in the embodimentsdescribed herein. Reference in the specification to “one embodiment,”“an embodiment,” “another embodiment,” or their variations means that aparticular feature, structure, or characteristic described in connectionwith the embodiments is included in at least one of the embodimentdescribed herein, and multiple references to “one embodiment,” “anembodiment,” “another embodiment,” or their variations should not beunderstood as necessarily all referring to the same embodiment.

As used herein, a “computer network,” a “network,” and their variationsrefer to a collection of interconnected computing devices that canexchange data with each other. Examples of a computer network include,but are not limited to, a peer-to-peer network and a network based onthe client-server model. In a computer system, interconnected computingdevices exchange data with each other using a communication mechanism.The connections between interconnected computing devices are establishedusing either wired or wireless communication mechanisms. Examples ofcommunication mechanisms include, but are not limited to, any type ofdata network such as a local area network (LAN), a wide area network(WAN) such as the Internet, a fiber network, a storage network, or acombination thereof, wired or wireless. The communication mechanismsalso include networking hardware (e.g., switches, gateways, routers,network bridges, modems, wireless access points, networking cables, linedrivers, switches, hubs, repeaters, etc.).

As used herein, a “computing device,” a “programmable device,” and itsvariations refer to a device that can be instructed to carry out a setof arithmetic or logical operations automatically. In some embodiments,a computing device comprises one or more of a processing element (e.g.,a central processing unit (CPU), a microprocessor, etc.), some form ofmemory, and peripheral interfaces. Examples include, but are not limitedto, a mobile computing device, a lap top computer, a wearable computingdevice, a network device, an internet of things (IoT) device, a cloudcomputing device, a vehicle, a smart lock, etc.

As used herein, a “secure network,” a “secure computer network,” andtheir variations refer to a computer network that requires end-users toauthenticate themselves before the end-users can access the network.Authentication can be achieved using any known authenticationtechnologies (e.g., an authentication service, an authentication server,etc.).

As used herein, a “context-aware network” and variations thereof referto an adaptive system, including a security system, of interconnectedservices that communicate and share information to make real-time,accurate decisions by individual products and/or as a collective. In oneexample, the context-aware network is achieved using an enterpriseservice bus (ESB) that interconnects at least some of the programmabledevices in a computer network.

As used herein, an “enterprise service bus” (“ESB”) and variationsthereof refer to a software-based network architecture that provides amedium of data exchange over a service-oriented architecture. In someembodiments, an ESB is a special case of a client-server softwarearchitecture in which clients may route messages or gathered datathrough a server.

As used herein, a “data exchange layer” (“DXL”) and variations thereofrefer to a type of ESB that is suitable for exchange of security-relatedmessages (e.g., gathered data associated with authentication,context-based authentication messages based on processing of thegathered data, etc.). In this way, a DXL can assist with providing acontext of a user attempting to access a secure network. An example of aDXL is the McAfee® Data Exchange Layer (DXL). (MCAFEE is a registeredtrademark of McAfee, Inc.).

FIG. 1 is a schematic diagram of an embodiment of a computer network 100where embodiments of the present disclosure may operate. Computernetwork 100 comprises a plurality of communication mechanisms 102, whereeach of the communication mechanisms 102 may contain a number of otherdevices (e.g., microcontrollers, embedded systems, industrial controlcomputing modules, etc.). Specifically, communication mechanisms 102comprise one or more different types of computer networks availabletoday, such as the Internet, enterprise networks, data centers, a widearea networks (WAN), and/or a local area networks (LAN). Each of thesenetworks within communication mechanisms 102 may contain wired and/orwireless programmable devices that operate in the electrical and/oroptical domain, and also employ any number of network communicationprotocols (e.g., TCP/IP). For example, one or more of the networkswithin communication mechanisms 102 may be a wireless fidelity (Wi-Fi®)network, a Bluetooth® network, a ZigBee® network, and/or any othersuitable radio based network as would be appreciated by one of ordinaryskill in the art upon viewing this disclosure.

Communication mechanisms 102 may also comprise switches, routers, and/orother network hardware devices configured to transport data overcommunication mechanisms 102. Moreover, communication mechanisms 102 maybe configured to implement computer virtualization, such as virtualprivate network (VPN) and/or cloud based networking. FIG. 1 illustratesthat communication mechanisms 102 may be connected to computing devices106, computer servers 104, and one or more network nodes 108, whichinclude, but are not limited to, gateways, routers, and/or wirelessaccess points. The computing devices 106 and/or computer servers 104 mayeach comprise a plurality of virtual machines (VMs), containers, and/orother types of virtualized computing systems for processing computinginstructions and transmitting and/or receiving data over communicationmechanisms 102. For example, the computing devices 106 and computerservers 104 may be configured to support a multi-tenant architecture,where each tenant may implement its own secure and isolated virtualnetwork environment. Although not illustrated in FIG. 1, the computernetwork 100 may use communication mechanisms 102 to connect a variety ofother types of computing devices, such as VMs, containers, hosts,storage devices, electronic devices (e.g., wearable electronic devices),and/or any other electronic device capable of transmitting and/orreceiving data over communication mechanisms 102. The functionality ofthe network node(s) 108 may be implemented in any device or combinationof devices illustrated in FIG. 1; however, most commonly is implementedin a firewall or intrusion protection system in a gateway or router.

As shown in FIG. 1, computer network 100 may also comprise a cellularnetwork 103 for use with mobile communication devices. The cellularnetwork 103 may be capable of supporting of a variety of devices thatinclude, but are not limited to computers, laptops, and/or a variety ofmobile devices (e.g., mobile phones). Using FIG. 1 as an example,devices in the computer network 100 may communicate via the cellularnetwork 103 are illustrated as mobile phones 110, laptops 112, andtablets 114. A mobile device, such as mobile phone 110, may interactwith one or more mobile provider networks as the mobile device moves,typically interacting with a plurality of mobile network towers 120,130, and 140 for connecting to the cellular network 103. Althoughreferred to as a cellular network 103 in FIG. 1, a mobile device mayinteract with towers of more than one provider network, as well as withmultiple non-cellular devices such as network node(s) 108. In addition,the mobile devices 110, 112, and 114 may interact with non-mobiledevices such as computers 104 and computer servers 106 for desiredservices.

In one or more embodiments, one or more mobile devices (e.g., mobilephones 110, laptops 112, and tablets 114), computer servers 104,computing devices 106, and/or other devices may support trustedoperations through the employment of a trusted execution environment(TEE). For example, a TEE may implemented using Intel® Software GuardExtensions (SGX), Intel® Converged Security Engine (CSE), Intel®Virtualization Technology, ARM® TrustZone® technology, and/or Intel®Manageability Engine (ME). (INTEL is a registered trademark of IntelCorp. ARM and TRUSTZONE are registered trademarks of ARM Limited.)Trusted networks may be formed dynamically using trusted discovery whichallows trusted network devices to discover other trusted networkdevices, or trusted network nodes, that include a trusted entity. Forpurposes of the current disclosure, trusted networks may be formed byany means that allow services on trusted devices to remain opaque tonetwork devices that are not part of the trusted network. Whereasuntrusted discovery may reveal whether a particular node or networkdevice may support trusted discovery, trusted discovery may be necessaryto reveal additional trusted capabilities and services among trusteddevices. Some examples of protocols that may be revealed only by trusteddiscovery include attestation, key agreement, group formation, trustedproxy, and provisioning. At least some embodiments of the context-awareauthentication described herein occurs within a TEE. For example, one ormore logic/modules within or coupled to one or more mobile devices(e.g., mobile phones 110, laptops 112, and tablets 114), computerservers 104, computing devices 106, and network node(s) 108 used foracquisition and/or processing of data associated with context-awareauthentication operates within a TEE.

In one embodiment, one or more of the network node(s) 108 and thecomputer server(s) 104 acts as an authentication entity that executes anauthentication service. That is, the node(s) 108 and/or the server(s)104 work together to perform one or more of techniques used to verify auser identity attempting to access the secure computer network 100 viaone or more mobile devices (e.g., mobile phones 110, laptops 112, andtablets 114) and/or computing devices 106.

As described above, the computer network 100 includes severalcomponents. In at least one embodiment, these components operatetogether as a context-aware network that includes a security system forfacilitating context-aware authentication as described herein.Additional details about one or more embodiments of context-awareauthentication are provided below in connection with one or more ofFIGS. 2-6.

Referring now to FIG. 2, which is a sequence diagram illustrating atechnique 200 for context-aware authentication implemented via acontext-aware network that includes a security system according to oneembodiment. The context-aware network in FIG. 2 can be part of thecomputer network 100 described above in connection with FIG. 1. Thecontext-aware network in FIG. 2 includes computing device(s) 202A-N, ESB204, authentication entity 206, and authorization entity 208. Each ofcomputing device(s) 202A-N, ESB 204, authentication entity 206, andauthorization entity 208 may include wired communication mechanisms,wireless communication mechanisms, and all other necessary networkinghardware and/or software required for communication. For brevity and toavoid obscuring the inventive concepts described herein, the data storesand/or computing devices to be accessed in response to successfulauthentication are not shown in FIG. 2.

Technique 200 begins at operations 251A-N. Here, users attempting toaccess a secure network (e.g., the computer network 100 of FIG. 1, etc.)via computing device(s) 202A-N enter into authentication sessions. Forbrevity, only operation 251A (and device 202A) will be described inconnection with FIGS. 2, 3, 4, 5, and 6.

With regard again to FIG. 2, each device 202 can be associated with useridentity (e.g., a user account, etc.). For example, an employee of anorganization user may use his device 202A to access an intranet thataccessible only to the organization's staff. Generally, a wide range ofinformation and services from the organization's internal informationtechnology (IT) systems are available that would not be available to thepublic. As such, a context-aware network that includes a security system(e.g., the context-aware network in FIG. 2, etc.) may be in place toensure that only users with authorization (i.e., the organization'sstaff) have access to the intranet.

As shown in FIG. 2, each device 202 is a computing device that executesvarious types of processing including enabling a user of the device202A-N to authenticate himself/herself via an authentication session inorder to gain access to a secure network. In one embodiment, the devices202 includes or is coupled to a context-aware authenticationlogic/module 201 (described in further detail below). Also, the devices202 can include one or more electronic components 230 used to implementthe context-aware authentication logic/module 201. Examples of the oneor more electronic components 230 include: processing unit(s) (such asmicroprocessors, co-processors, other types of integrated circuits(ICs), etc.); corresponding memory; and/or other related circuitry. Insome embodiments, the context-aware authentication logic/module 201 isimplemented as one or more special-purpose processors with tamperresistance features. Examples of such special-purpose processors includea trusted platform module cryptoprocessor, an application specificintegrated circuit, an application-specific instruction set processor, afield programmable gate array, a digital signal processor (DSP), anytype of cryptographic processor, an embedded processor, a co-processor,or any other type of logic with tamper resistance features that iscapable of processing instructions. In this way, the context-awareauthentication logic/module 201 can be implemented and maintained in asecure manner that assists with minimizing or preventing securityvulnerabilities. For a further embodiment, the context-awareauthentication logic/module 201 may be maintained separately from thecomponents 230. For example, the context-aware authenticationlogic/module 201 may be implemented as one or more special-purposeprocessors that are separate from the components 230.

As explained above, the context-aware authentication logic/module 201may be implemented by a processor. In a specific embodiment, thelogic/module 201 operates within a trusted environment (e.g., a TEE,etc.). The logic/module 201 may be part of an authentication session.Other devices that are not shown in FIG. 2 that may also include thecontext-aware authentication logic/module 201 include access controldevices, such as a door control systems, and/or other common securitycontrol devices. In one embodiment, the context-aware authenticationlogic/module 201 gathers at least some of the data associated withauthenticating a user of the device 202 that is attempting to gainaccess to the computer network (e.g., network 100 of FIG. 1, etc.) beingserviced by the context-aware network in FIG. 2. In an embodiment, thecontext-aware authentication logic/module 201 stores at least some ofthe data associated with authentication including, but not limited to,the following: (i) identity data used to facilitate authentication(e.g., private identifying information, legal identifying information,administrator-assigned credentials, etc.); and (ii) contextual datacorresponding to the identity data (e.g., timestamp information,geolocation coordinates (e.g., Global Positioning System (GPS)coordinates), unique computer identifiers (e.g., internet protocol (IP)address, VPN address, etc.), random numbers, one time password (OTP)sequences, etc.). The gathered data may be communicated via an ESB 204(described in further detail below) and stored in a security accessdatabase 210 (described in further detail below). Identity data can beany of three authentication factors. Examples of identity data include,but are not limited to, a user's social security number, a user's name,a user's contact information, a user's demographic data, a username andcorresponding password; a physical or virtual object (e.g., a smartcard, a public key infrastructure (PKI) certificate, a digital token,etc.); biometrics, and/or a set of questions that the user must answer.The database 210 may be any suitable data store, including a structuredor relational database, a distributed database, an operational database,an object-oriented database, a multi-dimensional database, etc.

In one embodiment, operation 251 includes the logic/module 201communicating the data gathered by the logic/module 201 via an ESB 204.The ESB 204, in one embodiment, is a software-based network architecturethat provides a medium for secure data exchange within the context-awarenetwork of FIG. 2. In some embodiments, an ESB is a special case of aclient-server software architecture in which clients (e.g., computingdevices, servers, network nodes, etc.) may route messages or gathereddata through one or more ESB servers. The ESB 204 can reside in anynetwork element, including a dedicated computer, an Ethernet switch, anaccess point, a network access server, and any other known technologycapable of implementing a medium for secure data exchange within acontext-aware network. For example, the ESB 204 is implemented in one ormore network nodes (e.g., network node(s) 108 in FIG. 1, etc.) and/orone or more computer servers (e.g., computer server(s) 104 in FIG. 1,etc.). Additional details about the ESB 204 are described below inconnection with at least FIG. 3.

Technique 200 proceeds to operation 253, where an authentication entity206 receives the gathered data via the ESB 204. In one embodiment, theauthentication entity 206 can be a network service that facilitatesauthentication of a user of device 202A attempting to access a network(e.g., the network 100 of FIG. 1, etc.). The authentication entity 206can reside in any network element, including a dedicated computer, anEthernet switch, an access point, a network access server, and any otherknown technology capable of implementing an authentication service. Forexample, the authentication entity 206 is implemented in one or morenetwork nodes (e.g., network node(s) 108 in FIG. 1, etc.) and/or one ormore computer servers (e.g., computer server(s) 104 in FIG. 1, etc.). Inone embodiment, the authentication entity 206 includes one or more of asecurity access database 210, a user behavior (UBA) logic/module 211,and a context-aware decision logic/module 212. In a specific embodiment,one or more of the database 210, the UBA logic/module 211, and thecontext-aware decision logic/module 212 is implemented in one or moreelectronic components 231. Examples of the one or more electroniccomponents 231 include: processing unit(s) (such as microprocessors,co-processors, other types of integrated circuits (ICs), etc.);corresponding memory; and/or other related circuitry.

In one embodiment, operation 253 includes organizing/storing thegathered data into a security access database 210. The security accessdatabase 210 can be a collection of information that includes thegathered data (i.e., the identity data and the contextual data)organized in such a way that a computing device can select, process,and/or update desired pieces of data. A UBA logic/module 211 may use thegathered data in the security access database 210 for furtherprocessing. For example, and in one embodiment, the UBA logic/module 211may process the gathered data using user behavior analytics (UBA)technologies to identify one or more patterns associated with userbehaviors. As used herein, “user behavior analytics,” “UBA,” and theirvariations refer to a cybersecurity process for detection of insiderthreats, targeted attacks, and security vulnerabilities within acomputer network. UBA technologies collect and analyze patterns ofusers' data and activities. For example, one UBA technique includescollecting and analyzing human behavior (e.g., network log-in times,network log-out times, geolocations associated with accessing a network,etc.) and then applying algorithms and statistical analysis to detectmeaningful anomalies from those patterns—anomalies that indicatepotential threats. The results of the processing performed by the UBAlogic/module 211 may be stored in the security access database 210. UBAtechnologies are known so they are not described in detail in thisdocument.

In at least one embodiment, operation 253 also includes providing theinformation stored in the security access database 210 to acontext-aware decision logic/module 212, which may be part of theauthentication entity 206 (as shown in FIG. 2). When a user of device202A attempts to access a computer network (e.g., the network 100 ofFIG. 1, etc.), the context-aware decision logic/module 212 uses theinformation associated with the current authentication session (i.e.,the current identity data and the current contextual data being used forthe current authentication session) and the data stored in the securityaccess database 210 to determine a risk level associated with thecurrent authentication session. If the risk level fails to exceed athreshold, the decision logic/module 212 does not trigger additionalauthentication sessions for the user of device 202. That is, thedecision logic/module 212 will “inform” the authentication entity 206 togrant the user of device 202 access to the secure network based on thecurrent authentication session (assuming the identity data used by theuser of device 202 is in fact the correct information for successfulauthentication). Alternatively, if the risk level exceeds the threshold,the decision logic/module 212 triggers additional authenticationsessions for the user of device 202A. Here, the decision logic/module212 will cause the authentication entity 206 to request additionalidentity data from the user to establish confidence that the user is infact who he/she claims to be. In some embodiments, each of the risklevel and the threshold may be represented as a value (e.g., a number,an array of numbers, etc.). In one embodiment, the decision logic/module212 uses the results of the UBA logic/module 211 stored in the securityaccess database 210 together with the data gathered by the context-awareauthentication logic/module 201 to determine whether a user of device202 will be granted access based on the current authentication session.For example, if a user attempts to access a secure network (e.g., thenetwork 100, etc.) via the computing device 202A at 3:00 AM, thedecision logic/module 212 can use the data in the security accessdatabase 210 to determine whether this attempt complies with the user'sknown behavior patterns. In this example, if the decision logic/module212 determines that the behavior is legitimate because it complies withwhat is known about the user (i.e., the user normally accesses thesecure network during early morning hours), then the decisionlogic/module 212 will notify the authorization entity 206 that the usermay be granted access without additional identity data being requestedfrom the user (assuming the current identity is the current identitydata for authentication). On the other hand, if the decisionlogic/module 212 determines that the attempt does not conform to theuser's known behavior patterns (i.e., the user hardly or never accessesthe secure network during early morning hours), then the decisionlogic/module 212 will cause the authentication entity 206 to requestadditional identity data from the user. In one or more embodiments, theauthentication entity 206's request is randomized. That is, therequested additional data is different each time such a request istriggered. In this way, the user (or a malicious party acting as theuser) cannot predict what type of additional identity data is needed.This can assist with strengthening the authenticating technique 200 andwith minimizing or eliminating unauthorized individuals (e.g., hackers,etc.) from accessing the network 100.

In some scenarios, a user of device 202A may fail to provide the propercredentials required for access to the secure network. These propercredentials include the initial identity data for the currentauthentication session, the contextual data associated with the initialidentity data, and the additional identity data requested by theauthentication entity 206. In such scenarios, an authorization entity208 can be invoked. The authorization entity 208 can, in one embodiment,implement one or more authorization services associated with grantingthe user of device 202 with approval to access the secure network and/orapproval to perform one or more actions within the secure network. Theauthorization entity 208 can, for example, include one or moreelectronic components 232 (including software and/or hardware) thatenable one or more network administrators to grant authorization to auser of device 202, register the user's identity data with theauthentication entity 206, and/or reset the user's authenticationfactors. Examples of the one or more electronic components 232 include:processing unit(s) (such as microprocessors, co-processors, other typesof integrated circuits (ICs), etc.); corresponding memory (storing dataincluding software); and/or other related circuitry. In one embodiment,the authorization entity 208 is implemented in one or more network nodes(e.g., network node(s) 108 in FIG. 1, etc.) and/or one or more computerservers (e.g., computer server(s) 104 in FIG. 1, etc.). As shown in FIG.2, technique 200 can include one or more operations 255A and 255B. Inone embodiment, operation 255A includes the authentication entity 206communicating with the authorization entity 208 via the ESB 204. In oneembodiment, operation 255B includes the authentication entity 206communicating directly with the authorization entity 208 without usingthe ESB 204.

In at least one embodiment, each of operations 251, 253, and 255A-B caninclude generating and presenting a user interface on a display topresent information related to the technique 200. For example, a userinterface (e.g., a graphical user interface, etc.) can be generated andpresented on a display of device 251 to request identity data from theuser, to present acquired contextual data associated with the user, topresent the determined risk level associated with the user, to indicatethat additional identity is required from the user, to presentinformation associated with invoking an authorization entity 208, etc.

As shown above, technique 200 is directed to a context-awareauthentication technique. This technique 200 can assist with improvingcomputer functionality by intelligently improving authenticationtechniques used for accessing a secure computer network. In particular,at least one embodiment of the technique 200 described herein can assistwith dynamically adjusting authentication requirements required for auser to gain access to a secure network based on one or more attributesassociated with the user. This dynamic adjustment of authenticationrequirements can in turn assist with minimizing or eliminating risks tothe operational integrity of a secure network caused by vulnerabilitiesin the authentication technique on an as-needed basis. In this way,computer resources associated with authentication can be utilized moreefficiently.

FIG. 3 is a block diagram illustrating an enterprise service bus (ESB)300 for use in context-aware authentication according to one embodiment.The ESB 300 can be part of the context-aware network illustrated in FIG.2. In one embodiment, the ESB 300 provides a specific architecture forcommunication within a context-aware network (e.g., the network in FIG.2, etc.). In one embodiment, the ESB 300 comprises one or more ESBendpoints 314, at least two sets of communication mechanism(s) 322A-B,an ESB broker server 310, and an ESB master server 312.

As shown in FIG. 3, the computing devices configured to exchange datavia the ESB 300 may be referred to as ESB endpoints 314. These mayinclude a plurality of device(s) 302A-N (which is the same as or similarto the plurality of devices 202A-N described above in connection withFIG. 2), an authentication entity 306 (which is the same as or similarto the authentication entity 206 described above in connection with FIG.2), and an authorization entity 308 (which is the same as or similar tothe authorization entity 208 described above in connection with FIG. 2).In one embodiment, the ESB endpoints 314 exchange identity data andcontextual data associated with authentication in a secure environmentprovided by the ESB 300. That is, in this embodiment, the ESB 300 acts aspecialized communication fabric. In a further embodiment, the ESB 300may be provided on top of an existing communication network, such as alocal area network (LAN).

The communication mechanism(s) 322A-B of the ESB 300 may include anytype of physical or virtual network connection over which appropriatedata may pass. The ESB 300 includes any network technology or topologysuitable for message exchange. In one embodiment, the ESB 300 utilizesmessage queuing telemetry transport messages for data exchange.

The ESB 300 includes an ESB broker server 310, which may be configuredto provide ESB messaging services, such as maintaining ESB routingtables and delivering messages. In one embodiment, all data communicatedbetween the endpoints 314 passes through the ESB broker server 310. Thiscan assist with being minimizing or eliminating attacks by maliciousparties (e.g., man-in-the-middle attacks, etc.) that attempt to stealidentity data and/or contextual data associated with authentication.

In at least one embodiment, the ESB master server 312 is communicativelycoupled to the ESB broker server 310 via the communication mechanism(s)322B. The ESB master server 312 may maintain domain data in a data store(not shown). For example, the ESB master server 312 may maintain domaindata on a memory that is local to the ESB master server 312, or memorythat is coupled to the ESB master server 312. This memory may beseparately or remotely hosted.

The ESB 300 can, for example, operate as follows. A device 302A (e.g., amobile computing system, a wearable, a vehicle, etc.) connects to thecommunication mechanism(s) 322A (e.g., a LAN, etc.) and receives a newunique identifier (e.g., an IP address, etc.). At this point, identitydata and contextual data (collectively referred to as “gathered data”)corresponding to the connected device 302A becomes known or knowable tothe authentication entity 306, the authorization entity 308, and/or theESB broker server 310. This gathered data includes any known identitydata and/or contextual data associated with authentication as describedabove in connection with one or more of FIGS. 1 and 2 above. Examplesinclude, but are not limited to, the unique computer identifiers (e.g.,IP address, VPN address, etc.) associated with the device 302A,information about an operating system running on the device 302A, theusername for the user logged on to the device 302A, timestampinformation associated with the connection of the device 302A to thecommunication mechanism(s) 322A, geolocation coordinates (e.g., GPScoordinates) associated with the device 302A, random numbers generatedin response to the device 302A connecting to the communicationmechanism(s) 322A, OTP sequences required for the device 302A to connectto the communication mechanism(s) 322A, etc.

In one embodiment, the device 302A publishes one or more messages toreport the gathered data associated with the device 302A to the ESBbroker server 310. In yet another embodiment, the authentication entity306 and/or the authorization entity 308 may also publish one or moremessages to report the gathered data associated with the device 302A tothe ESB broker server 310. The ESB broker server 310 provides thegathered data associated with the device 302A to the ESB master server312 via the communication mechanism(s) 322B. Here, the ESB master server312 is responsible for maintaining the records of the gathered dataassociated with the device 302A.

The ESB master server 312 may combine and reconcile the gathered dataassociated with the device 302A that is received from the two sourcesinto a single record of truth, containing single values for the gathereddata. For example, if the ESB master server 312 receives the gathereddata associated with the device 302A from the device 302A itself andfrom the authentication entity 306, the ESB master server 312 reconcilesthese records to determine a single “correct” version of the gathereddata. The reconciled version of the gathered data may be persistentlystored in a domain database, and the ESB master server 312 may thenpublish the reconciled version of the gathered data on the ESB 300. Thebroker server 310 may then forward the published message to one or moreof the endpoints 314.

The ESB 300 may be based on a two-layer protocol. The “bottom” layer isa secure, reliable, low-latency data transport fabric that connectsdiverse security elements as a mesh, or in a hub-and-spokeconfiguration. The “top” layer is an extensible data exchange frameworkthat is configured to facilitate trustworthy data representation. In anexample, the endpoints 314 connect to the ESB 300. Each endpoint 314 isassigned a distinct identity, and authenticates itself to authenticationentity 306 upon connection via the communication mechanism(s) 322A. Eachendpoint 314 may establish one-to-one communications via the ESB 300,for example by sending a message addressed to an endpoint 314 with aspecific identity. This enables endpoints 314 to communicate with eachother without having to establish a point-to-point network connection.In another example, one or more of the ESB endpoints 314 “subscribe” tomessages of a certain type. When an endpoint 314 “publishes” a messageof that type on the ESB 300, all other endpoints 314 that subscribe tothe message will receive and process the message, while non-subscribersmay safely ignore it. In yet another example, one endpoint 314 maypublish a request over the ESB 300. Here, an appropriate one of theother endpoints 314 receiving the request may provide a response.Advantageously, the response may be used by more than just the endpoint314 that originally published the request. For example, after theauthentication entity 306 publishes a request for gathered dataassociated with the device 302A and receives the requested data, theentity 306 can also publish the requested information on the ESB 300. Inthis way, other endpoints 314 (e.g., the authorization entity 308, etc.)that find instances of the requested data may benefit from the publisheddata without having to request it.

The ESB 300 may be implemented using diverse software elements,patterns, and constructs suited to the specific infrastructureconnecting the security elements. For instance, in a physical enterprisenetwork, messaging middleware consisting of multiple interconnectedmessage brokers may be deployed, where endpoints 314 connect to theclosest broker 310 in an ESB 300 comprised of multiple brokers 310. In avirtual network infrastructure, the fabric may leverage hypervisorprovided channels.

In one embodiment, the ESB master server 312 may transform data receivedfrom the ESB endpoints 314 into a well-understood, standardizedrepresentation. This representation may be published on ESB 300, so thatall endpoints 314 receive usable data. In some embodiments, each of theendpoints 314 includes an ESB logic/module (e.g., the context-awareauthentication logic/module 201A, the context-aware decisionlogic/module 212, etc.) that enables the respective endpoint 314 to useits own local APIs for querying and receiving data. To increase networkefficiently, the endpoints 314 may cache received data locally, untilsuch data is superseded by an authorized message. For example, theauthentication entity 306 may subscribe to publications about thegathered data for one or more of the devices 302A-N. When suchpublications are made, the authentication entity 306 may store thegathered data in a local database (e.g., the security access database210 described above in connection with FIG. 1, etc.). The storedgathered data may be used until it is superseded by updatedpublications.

FIG. 4 is a flowchart illustrating a technique 400 for context-basedauthentication according to one embodiment. The technique 400 can beperformed by one or more elements of the network 100 described above inconnection one or more FIGS. 1-3. For example, a processor (e.g., a TEEof a processor, a cryptoprocessor with tamper resistance features, anyprocessor known in the art, etc.) implementing a network node 108 and/ora server 104 as described above in connection with FIG. 1, etc.Technique 400 includes some elements of the network 100 described abovein connection one or more FIGS. 1-3. For the sake of brevity, theseelements are not described again.

Technique 400 begins at operation 401, where an authentication sessionis initiated. Generally, one or more computing devices (e.g., devices114, 112, 110, 106 of FIG. 1, devices 202A-N of FIG. 2, devices 302A-Nof FIG. 3, etc.) authenticates with its credentials and receives asession identifier (which can, for example, be stored in a cookie). Insome scenarios, the session identifier may be considered a token becauseit is the equivalent of a set of credentials. An authentication entity206 associates the session identifier with a user account (e.g. inmemory, or in a database). In at least one embodiment, a user interface(e.g., a graphical user interface, etc.) can be used for operation 401.The entity 206 can also restrict or limit the authority associated withthe session identifier to certain operations or a certain time period.Additionally, the entity 206 may invalidate the session identifier andrevoke the granted authority associated with the session identifier ifor when there are security concerns. Generally, changes to theauthorizations granted to a session identifier can be changed usingpolicies set by one or more network administrators. Another feature of asession identifier is that its enables tracking the activitiesundertaken by a user associated with the session identifier while he/sheis granted access to the secure network.

At operation 402, technique 400 includes gathering data associated withthe current authentication session. In one embodiment, the gathered datais similar to or the same as the gathered data described above inconnection with one or more FIGS. 1-3. In at least one embodiment, auser interface (e.g., a graphical user interface, etc.) can be used topresent the information gathered during operation 402. In someembodiments, the gathered data can be deemed attributes associated witha user account that corresponds to the device on which authentication isperformed. In one embodiment, these attributes are unique markersassociated with the user account for determining a risk level associatedwith the current authentication session of the user account. Thegathered data can also include identity data and contextual data thathas been acquired over a period of time (e.g., data associated withprior authentication sessions for that specific user account, etc.). Inone embodiment, technique 400 proceeds to operation 412. Here, machinelearning is applied to the gathered data to identify the user requestingaccess to a secure network and the risk level associated with thecurrent authentication session. In one embodiment, the gathereddata/attributes are categorized as follows:

Access Type—This data refers to the known status of the device beingused for authentication, including device identifying information (e.g.,unique computer identifiers, etc.). More specifically, a risk level isdetermined, increased, or decreased based on whether the user account isrequesting access to a secure network through a personal device, amobile device, a networked device, a public shared device, or otherdevice. For example, when the user attempts to access the secure networkfrom a network-approved device (a device assigned by the owner of thesecure network, etc.), the authentication attempt may be deemed lessrisky than when the user attempts to access the secure network via apersonal device that has not been approved by the owner of the securenetwork.

Attribute Type—This data refers to location and communication mechanisms(e.g., LAN, WAN, etc.) being used to request access to a secure network.Here, a risk level is determined, increased, or decreased based on alocation and/or a communication mechanism associated with the currentauthentication session. For example, when a user attempts to access thesecure network via a physical communication mechanism (e.g., a wiredconnection), the wired connection may be deemed less risky than when theuser attempts to access the secure network via a virtual communicationmechanism (e.g., a wireless connection). Additionally, the larger thedistance between a geolocation where the user attempts to access thesecure network and a predetermined “safe” geolocation can also be usedto determine a risk level of the attempted access. Examples of a “safe”geolocation include, but are not limited, an address associated with theowner of the secure network.

Attribute Accuracy—Depending on the attribute type, this data relates tothe number of authentication factors that can be implemented from theattribute type. Here, a risk level is determined, increased, ordecreased based on a presence or absence of an authentication factor tothe user requesting access. For example, if one form of authenticationrequires the user to authenticate via inputs provided in response to atelephone call, but the user is unable to receive the call, then thisfailure can be used to elevate a risk level of attempted access.

Frequency and Manner of Authentication attempts—This data relates to thespeed with which the user attempts to re-authenticate or retry, theknown times when the user is likely to access the secure network, andthe known behavior about the user's authentication patterns. Based onthis data, a risk level associated with the attempted access can bedetermined, reduced, or increased. For example, if a user attempts toaccess a secure network at 3:00 AM, the data in the security accessdatabase can be used to determine whether this attempt complies with theuser's legitimate behavior patterns. In this example, if a determinationis made that the behavior is legitimate (e.g., the user normallyaccesses the secure network during early morning hours), then a risklevel can be minimal or non-existent. On the other hand, if adetermination is made that the attempt does not conform to the user'slegitimate behavior patterns (e.g., the user hardly or never accessesthe secure network during early morning hours), then a risk level can beincreased.

In response gathering the data/attributes and determining thepattern(s), technique 400 performs operation 403. Here, gathereddata/attributes and/or the pattern(s) are processed to determine a risklevel associated with the current authentication session. In at leastone embodiment, a user interface (e.g., a graphical user interface,etc.) can be used to present the information about the determined risklevel during operation 403. Each of the different categories ofattributes described above can be weighted in determining the risklevel. In one embodiment, there are at least two risk levels that can bedetermined using the gathered data/attributes, as described above inconnection with at least FIG. 1.

Next, at operation 404, a determination is made about the risk level bycomparing the risk level with a threshold. In at least one embodiment, auser interface (e.g., a graphical user interface, etc.) can be used topresent the information about the determination being during operation404. If the comparison indicates an acceptable risk level, based on apredetermined relationship with the threshold (e.g., the risk level doesnot exceed the threshold), then authentication proceeds using theidentity data provided during operation 402 (i.e., the initial identitydata provided for the current authentication session). If theauthentication is successful (operation 405), then the user accountcorresponding to the device being used for authentication is grantedaccess to the secure network (operation 407). On the other hand, atoperation 404, if the comparison indicates an unacceptable risk levelbased on the predetermined relationship with the threshold (e.g., therisk level exceeds the threshold), then additional identity data must beprovided to the device being used for authentication by a user of thedevice before authentication can commence (operation 406). Anypredetermined relationship between the risk level and the threshold maybe used for the determination whether the risk level is acceptable. Insome embodiments, the threshold is configurable. In one embodiment ofoperation 406, the additional identity data is combined with the initialidentity data provided during operation 402 and used to authenticate theuser. If the authentication that is based on the initial identity dataand the additional identity data is successful (operation 405), then theuser account corresponding to the device being used for authenticationis granted access to the secure network (operation 407).

In one embodiment, technique 400 includes operation 408. This operationis performed when authentication is not successful due to the userfailing to provide the correct credentials (e.g., the initial identitydata, the additional identity data, etc.) being used for authentication.Here, use of an authorization entity can be invoked, as described abovein connection with one or more of FIGS. 1-3.

In at least one embodiment, a user interface (e.g., a graphical userinterface, etc.) can be used to present the information associated witheach of operations 405-408.

For a specific example of operations 404-408, four risk levels arepossible. These levels are as follows:

“None”—This risk rating allow access from the device with no challenge(assuming the authentication credentials used during the current sessionare proper).

“Low”—This risk rating requires at least one challenge to be completedby the user requesting access. Each challenge is randomized from thedifferent authentication factors available (e.g., password, pin,biometrics, secure key, mobile authentication (telephone call), etc.).

“Medium”—This risk rating requires at least one more challenge than thenumber of challenges used for a “low” risk rating.

“Maximum”—This risk rating requires at least one more challenge than thenumber of challenges used for a “medium” risk rating. Alternatively, oradditionally, this risk rating could trigger use of an authorizationentity to determine whether the user is in fact authorized to access thesystem, and to modify the authorization granted to the user by issuingcredentials to the user.

Other risk level definitions and numbers of risk levels may be used asdesired.

FIG. 5 is a block diagram that illustrates a programmable device 500,which may be used to implement the techniques described herein inaccordance with one or more embodiments (e.g., embodiments describedabove in connection one or more of FIGS. 1-4). The programmable device500 illustrated in FIG. 5 is a multiprocessor programmable device thatincludes a first processing element 570 and a second processing element580. While two processing elements 570 and 580 are shown, an embodimentof programmable device 500 may also include only one such processingelement.

Programmable device 500 is illustrated as a point-to-point interconnectsystem, in which the first processing element 570 and second processingelement 580 are coupled via a point-to-point interconnect 550. Any orall of the interconnects illustrated in FIG. 5 may be implemented as amulti-drop bus rather than point-to-point interconnects.

As illustrated in FIG. 5, each of processing elements 570 and 580 may bemulticore processors, including first and second processor cores (i.e.,processor cores 574A and 574B and processor cores 584A and 784B). Suchcores 574A, 574B, 584A, and 584B may be configured to execute computinginstruction code. However, other embodiments may use processing elementsthat are single core processors as desired. In embodiments with multipleprocessing elements 570, 580, each processing element may be implementedwith different numbers of cores as desired.

Each processing element 570, 580 may include at least one shared cache546. The shared cache 546A, 546B may store data (e.g., computinginstructions) that are utilized by one or more components of theprocessing element, such as the cores 574A, 574B and 584A, 584B,respectively. For example, the shared cache may locally cache datastored in a memory 532, 534 for faster access by components of theprocessing elements 570, 580. For one or more embodiments, the sharedcache 546A, 546B may include one or more mid-level caches, such as level2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a lastlevel cache (LLC), or combinations thereof. The memory 532, 534 mayinclude software instructions representing one or more the context-awareauthentication logic/module 201A and the authentication entity 206. Eachof the logic/modules 201A and the entity 206 is described above inconnection with at least FIG. 1, 2, 3, or 4.

While FIG. 5 illustrates a programmable device with two processingelements 570, 580 for clarity of the drawing, the scope of the presentinvention is not so limited and any number of processing elements may bepresent. Alternatively, one or more of processing elements 570, 580 maybe an element other than a processor, such as a graphics processing unit(GPU), DSP unit, a field programmable gate array, or any otherprogrammable processing element. Processing element 580 may beheterogeneous or asymmetric to processing element 570. There may be avariety of differences between processing elements 570, 580 in terms ofa spectrum of metrics of merit including architectural,microarchitectural, thermal, power consumption characteristics, and thelike. These differences may effectively manifest themselves as asymmetryand heterogeneity amongst processing elements 570, 580. In someembodiments, the various processing elements 570, 580 may reside in thesame die package.

First processing element 570 may further include memory controller logic(MC) 572 and point-to-point (P-P) interconnects 576 and 578. Similarly,second processing element 580 may include a MC 582 and P-P interconnects586 and 588. As illustrated in FIG. 5, MCs 572 and 582 couple processingelements 570, 580 to respective memories, namely a memory 532 and amemory 534, which may be portions of main memory locally attached to therespective processors. While MC logic 572 and 582 is illustrated asintegrated into processing elements 570, 580, in some embodiments thememory controller logic may be discrete logic outside processingelements 570, 580 rather than integrated therein.

Processing element 570 and processing element 580 may be coupled to anI/O subsystem 590 via respective P-P interconnects 576 and 586 throughlinks 552 and 554. As illustrated in FIG. 5, I/O subsystem 590 includesP-P interconnects 594 and 598. Furthermore, I/O subsystem 590 includesan interface 592 to couple I/O subsystem 590 with a high performancegraphics engine 538. In one embodiment, a bus (not shown) may be used tocouple graphics engine 538 to I/O subsystem 590. Alternately, apoint-to-point interconnect 539 may couple these components.

In turn, I/O subsystem 590 may be coupled to a first link 516 via aninterface 596. In one embodiment, first link 516 may be a PeripheralComponent Interconnect (PCI) bus, or a bus such as a PCI Express bus oranother I/O interconnect bus, although the scope of the presentinvention is not so limited.

As illustrated in FIG. 5, various I/O devices 514, 524 may be coupled tofirst link 516, along with a bridge 518 that may couple first link 516to a second link 520. In one embodiment, second link 520 may be a lowpin count (LPC) bus. Various devices may be coupled to second link 720including, for example, a keyboard/mouse 512, communication device(s)526 (which may in turn be in communication with the computer network503), and a data storage unit 528 such as a disk drive or other massstorage device which may include code 530 in one embodiment. The code730 may include instructions for performing embodiments of one or moreof the techniques described above. Further, an audio I/O 524 may becoupled to second link 520.

Note that other embodiments are contemplated. For example, instead ofthe point-to-point architecture of FIG. 5, a system may implement amulti-drop bus or another such communication topology. Although links516 and 520 are illustrated as busses in FIG. 5, any desired type oflink may be used. In addition, the elements of FIG. 5 may alternativelybe partitioned using more or fewer integrated chips than illustrated inFIG. 5.

FIG. 6 is a block diagram illustrating a programmable device 600 for usewith techniques described herein according to another embodiment.Certain aspects of FIG. 6 have been omitted from FIG. 6 in order toavoid obscuring other aspects of FIG. 6.

FIG. 6 illustrates that processing elements 670, 680 may includeintegrated memory and I/O control logic (“CL”) 672 and 682,respectively. In some embodiments, the 672, 682 may include memorycontrol logic (MC) such as that described above in connection with FIG.6. In addition, CL 672, 682 may also include I/O control logic. FIG. 6illustrates that not only may the memories 632, 634 be coupled to the CL672, 682, but also that I/O devices 644 may also be coupled to thecontrol logic 672, 682. Legacy I/O devices 615 may be coupled to the I/Osubsystem 690 by interface 696. Each processing element 670, 680 mayinclude multiple processor cores, illustrated in FIG. 6 as processorcores 674A, 674B, 684A and 684B. As illustrated in FIG. 6, I/O subsystem690 includes point-to-point (P-P) interconnects 694 and 698 that connectto P-P interconnects 676 and 686 of the processing elements 670 and 680with links 652 and 654. Processing elements 670 and 680 may also beinterconnected by link 650 and interconnects 678 and 688, respectively.The memory 632, 634 may include software instructions representing oneor more the context-aware authentication logic/module 201A and theauthentication entity 206. Each of the logic/modules 201A and the entity206 is described above in connection with at least FIG. 1, 2, 3, or 4.

The programmable devices depicted in FIGS. 5 and 6 are schematicillustrations of embodiments of programmable devices that may beutilized to implement various embodiments discussed herein. Variouscomponents of the programmable devices depicted in FIGS. 5 and 6 may becombined in a system-on-a-chip (SoC) architecture.

Program instructions may be used to cause a general-purpose orspecial-purpose processing system that is programmed with theinstructions to perform the operations described herein. Alternatively,the operations may be performed by specific hardware components thatcontain hardwired logic for performing the operations, or by anycombination of programmed computer components and custom hardwarecomponents. The methods described herein may be provided as a computerprogram product that may include a machine readable medium having storedthereon instructions that may be used to program a processing system orother device to perform the methods. The term “machine readable medium”used herein shall include any medium that is capable of storing orencoding a sequence of instructions for execution by the machine andthat cause the machine to perform any one of the methods describedherein. The term “machine readable medium” shall accordingly include,but not be limited to, tangible, non-transitory memories such assolid-state memories, optical and magnetic disks. Furthermore, it iscommon in the art to speak of software, in one form or another (e.g.,program, procedure, process, application, module, logic, and so on) astaking an action or causing a result. Such expressions are merely ashorthand way of stating that the execution of the software by aprocessing system causes the processor to perform an action or produce aresult.

At least one embodiment is disclosed and variations, combinations,and/or modifications of the embodiment(s) and/or features of theembodiment(s) made by a person having ordinary skill in the art arewithin the scope of the disclosure. Alternative embodiments that resultfrom combining, integrating, and/or omitting features of theembodiment(s) are also within the scope of the disclosure. Wherenumerical ranges or limitations are expressly stated, such expressranges or limitations may be understood to include iterative ranges orlimitations of like magnitude falling within the expressly stated rangesor limitations (e.g., from about 1 to about 10 includes, 2, 3, 4, etc.;greater than 0.10 includes 0.11, 0.12, 0.13, etc.). The use of the term“about” means ±10% of the subsequent number, unless otherwise stated.

Use of the term “optionally” with respect to any element of a claimmeans that the element is required, or alternatively, the element is notrequired, both alternatives being within the scope of the claim. Use ofbroader terms such as comprises, includes, and having may be understoodto provide support for narrower terms such as consisting of, consistingessentially of, and comprised substantially of. Accordingly, the scopeof protection is not limited by the description set out above but isdefined by the claims that follow, that scope including all equivalentsof the subject matter of the claims. Each and every claim isincorporated as further disclosure into the specification and the claimsare embodiment(s) of the present disclosure.

The following examples pertain to further embodiments.

Example 1 is a machine readable medium storing instructions forcontext-based authentication in a secure network comprised of multipleinterconnected programmable devices, comprising instructions whenexecuted by a machine cause the machine to: receive, from a programmabledevice, identity data and contextual data associated with a currentauthentication of a user attempting to access a secure network, the userbeing associated with the programmable device; determine, based on theidentity data and the contextual data, one or more patterns associatedwith the current authentication of the user; determine, based on theidentity data, the contextual data, and the one or more patterns, a risklevel associated with the current authentication of the user; and accessthe secure network in response to the determined risk level.

In Example 2, the subject matter of example 1 can optionally includethat the instructions for causing the machine to access the securenetwork comprise instructions for causing the machine to access thesecure network based only on the current authentication in response tocomparing the determined risk level with a threshold.

In Example 3, the subject matter of examples 1 or 2 can optionallyinclude that the instructions for causing the machine to access thesecure network comprise instructions for causing the machine to requestadditional identity data in response to determining that the determinedrisk level does not have a predetermined relationship with a threshold;and access the secure network based on the current authentication andthe additional identity data.

In Example 4, the subject matter of example 3 can optionally includethat the requested additional identity data is randomized.

In Example 5, the subject matter of examples 1, 2, 3, or 4 canoptionally further comprise instructions that when executed by themachine cause the machine to: determine that the authentication isunsuccessful; and invoke an authorization entity in response to thefailed authentication.

In Example 6, the subject matter of examples 1, 2, 3, 4, or 5 canoptionally include that one or more of the identity data, the contextualdata, and the one or more patterns is communicated via an enterpriseservice bus (ESB).

In Example 7, the subject matter of example 6 can optionally includethat the ESB includes a data exchange layer.

In Example 8, the subject matter of examples 6 or 7 can optionallyinclude that the ESB utilizes message queuing telemetry transportmessages for data exchange.

Example 9 is a method of context-based authentication in a securenetwork comprised of multiple interconnected programmable devices, themethod comprising: receiving, from a programmable device, identity dataand contextual data associated with a current authentication of a userattempting to access a secure network, the user being associated withthe programmable device; determining, based on the identity data and thecontextual data, one or more patterns associated with the currentauthentication of the user; determining, based on the identity data, thecontextual data, and the one or more patterns, a risk level associatedwith the current authentication of the user; and accessing the securenetwork in response to the determined risk level, wherein the accessingis performed by one or more processors.

In Example 10, the subject matter of example 9 can optionally includethat accessing the secure network comprises: accessing the securenetwork based only on the current authentication in response tocomparing the determined risk level with a threshold.

In Example 11, the subject matter of examples 9 or 10 can optionallyinclude that accessing the secure network comprises: requestingadditional identity data in response to determining that the determinedrisk level does not have a predetermined relationship with a threshold;and accessing the secure network based on the current authentication andthe additional identity data.

In Example 12, the subject matter of example 11 can optionally includethat the requested additional identity data is randomized.

In Example 13, the subject matter of examples 9, 10, 11, or 12 canoptionally further comprise: determining that the current authenticationis unsuccessful; and invoking an authorization entity in response to theunsuccessful current authentication.

In Example 14, the subject matter of examples 9, 10, 11, 12, or 13 canoptionally include that one or more of the identity data, the contextualdata, and the one or more patterns is communicated via an enterpriseservice bus (ESB).

In Example 15, the subject matter of example 14 can optionally includethat the ESB includes a data exchange layer.

In Example 16, the subject matter of examples 14 or 15 can optionallyinclude that the ESB utilizes message queuing telemetry transportmessages for data exchange.

Example 17 is a system for context-based authentication in a securenetwork comprised of multiple interconnected programmable devices, thesystem comprising: one or more processors; and a memory coupled to theone or more processors and storing instructions, wherein execution ofthe instruction by the one or more processors causes the one or moreprocessors to: receive, from a programmable device of the multipleinterconnected programmable devices, identity data and contextual dataassociated with a current authentication of a user attempting to accessa secure network, the user being associated with the programmabledevice; determine, based on the identity data and the contextual data,one or more patterns associated with the current authentication of theuser; determine, based on the identity data, the contextual data, andthe one or more patterns, a risk level associated with the currentauthentication of the user; and access the secure network in response tothe determined risk level.

In Example 18, the subject matter of example 17 can optionally includethat the instructions for causing the one or more processors to accessthe secure network comprise instructions for causing the one or moreprocessors to: access the secure network based only on the currentauthentication in response to comparing the determined risk level withthreshold.

In Example 19, the subject matter of examples 17 or 18 can optionallyinclude that the instructions for causing the one or more processors toaccess the secure network comprise instructions for causing the one ormore processors to: request additional identity data in response todetermining that the determined risk level does not have a predeterminedrelationship with a threshold; and access the secure network based onthe current authentication and the additional identity data.

In Example 20, the subject matter of example 19 can optionally includethat the requested additional identity data is randomized.

In Example 21, the subject matter of examples 17, 18, 19, or 20 canoptionally further comprise instructions that when executed cause theone or more processors to: determine that the authentication isunsuccessful; and invoke an authorization entity in response to thefailed authentication.

In Example 22, the subject matter of examples 17, 18, 19, 20, or 21 canoptionally include that one or more of the identity data, the contextualdata, and the one or more patterns are communicated via an enterpriseservice bus (ESB).

In Example 23, the subject matter of example 22 can optionally includethat the ESB includes a data exchange layer.

In Example 24, the subject matter of examples 22 or 23 can optionallyinclude that the ESB utilizes message queuing telemetry transportmessages for data exchange.

In Example 25, the subject matter of examples 17, 18, 19, 20, 21, 22,23, or 24 can optionally include that at least one of the one or moreprocessors is a cryptoprocessor.

In Example 26, the subject matter of examples 1, 2, 3, 4, 5, 6, 7, or 8can optionally include that one or more processors of the machine or theprogrammable device is a cryptoprocessor.

In Example 27, the subject matter of examples 9, 10, 11, 12, 13, 14, 15,or 16 can optionally include that at least one of the one or moreprocessors is a cryptoprocessor.

It is to be understood that the above description is intended to beillustrative, and not restrictive. For example, the above-describedembodiments may be used in combination with each other. Many otherembodiments will be apparent to those of skill in the art upon reviewingthe above description. The scope of the invention therefore should bedetermined with reference to the appended claims, along with the fullscope of equivalents to which such claims are entitled.

What is claimed is:
 1. A machine readable storage device or storage diskcomprising instructions that, when executed, cause a machine forcontext-based authentication in a secure network including multipleinterconnected programmable devices to at least: obtain, from aprogrammable device, identity data and contextual data associated with acurrent authentication of a user attempting to access the securenetwork, the user being associated with the programmable device, thecontextual data indicating a number of authentication factorsimplementable by the programmable device in connection with the currentauthentication, whether the programmable device is an approved devicefor the secure network, and whether the programmable device isattempting to access the secure network via a physical communicationmechanism; determine, based on the identity data and the contextualdata, one or more patterns associated with the current authentication ofthe user; determine, based on the identity data, the number ofauthentication factors indicated by the contextual data, and the one ormore patterns, a risk level associated with the current authenticationof the user; access the secure network in response to the determinedrisk level satisfying a threshold; request additional identity data inresponse to the determined risk level not satisfying the threshold; anddetermine whether to permit access to the secure network based on thecurrent authentication and the additional identity data.
 2. The machinereadable storage device or storage disk of claim 1, wherein therequested additional identity data is randomized.
 3. The machinereadable storage device or storage disk of claim 1, wherein theinstructions, when executed, further cause the machine to invoke anauthorization entity based on the determined risk level not satisfyingthe threshold and the additional identity data.
 4. The machine readablestorage device or storage disk of claim 1, wherein one or more of theidentity data, the contextual data, and the one or more patterns iscommunicated via an enterprise service bus (ESB).
 5. The machinereadable storage device or storage disk of claim 4, wherein the ESBincludes a data exchange layer.
 6. The machine readable storage deviceor storage disk of claim 4, wherein the ESB is to utilize messagequeuing telemetry transport messages for data exchange.
 7. A method forcontext-based authentication in a secure network including multipleinterconnected programmable devices, the method comprising: obtaining,from a programmable device, identity data and contextual data associatedwith a current authentication of a user attempting to access the securenetwork, the user being associated with the programmable device, thecontextual data indicating a number of authentication factorsimplementable by the programmable device in connection with the currentauthentication, whether the programmable device is an approved devicefor the secure network, and whether the programmable device isattempting to access the secure network via a physical communicationmechanism; determining, based on the identity data and the contextualdata, one or more patterns associated with the current authentication ofthe user; determining, based on the identity data, the number ofauthentication factors indicated by the contextual data, and the one ormore patterns, a risk level associated with the current authenticationof the user; permitting access to the secure network in response to oneor more processors determining the determined risk level satisfies athreshold; requesting additional identity data in response to the one ormore processors determining the determined risk level does not satisfythe threshold; and determining whether to permit access to the securenetwork based on the current authentication and the additional identitydata.
 8. The method of claim 7, wherein the requested additionalidentity data is randomized.
 9. The method of claim 7, further includinginvoking an authorization entity based on the determined risk level notsatisfying the threshold and the additional identity data.
 10. Themethod of claim 7, further including communicating one or more of theidentity data, the contextual data, and the one or more patterns via anenterprise service bus (ESB).
 11. The method of claim 10, furtherincluding utilizing a data exchange layer of the ESB.
 12. The method ofclaim 10, further including utilizing message queuing telemetrytransport messages for data exchange via the ESB.
 13. A system forcontext-based authentication in a secure network including multipleinterconnected programmable devices, the system comprising: one or moreprocessors; and a memory including instructions that, when executed,cause the one or more processors to: access identity data and contextualdata associated with a current authentication of a user attempting toaccess the secure network with a programmable device of the multipleinterconnected programmable devices, the contextual data indicating anumber of authentication factors implementable by the programmabledevice in connection with the current authentication, whether theprogrammable device is an approved device for the secure network, andwhether the programmable device is attempting to access the securenetwork via a physical communication mechanism; determine, based on theidentity data and the contextual data, one or more patterns associatedwith the current authentication of the user; determine, based on theidentity data, the number of authentication factors indicated by thecontextual data, and the one or more patterns, a risk level associatedwith the current authentication of the user; permit access to the securenetwork in response the determined risk level satisfying a threshold;request additional identity data in response to the determined risklevel not satisfying the threshold; and determine whether to permitaccess to the secure network based on the current authentication and theadditional identity data.
 14. The system of claim 13, wherein therequested additional identity data is randomized.
 15. The system ofclaim 13, wherein the one or more processors are to invoke anauthorization entity based on the determined risk level not satisfyingthe threshold and the additional identity information.
 16. The system ofclaim 13, wherein the one or more processors are to communicate one ormore of the identity data, the contextual data, and the one or morepatterns via an enterprise service bus (ESB).
 17. The system of claim16, wherein the ESB includes a data exchange layer.
 18. The system ofclaim 16, wherein the ESB is to utilize message queuing telemetrytransport messages for data exchange.
 19. The system of claim 13,wherein at least one of the one or more processors is a cryptoprocessor.